將樣式表放在頂部這一點我想應該沒有人反對的了，但將腳本放在底部這一點我想很多網站都習慣直接放在樣式下面，我們的taoche也是一樣。

如果對于小網站來說這樣并無所謂，但對于每天幾十萬流量的大網站來說，這就影響大了，就像蝴蝶效應。

我們找個例子：
打開易車網的首頁,查看源代碼，我們會發現除了一個基本JS外，其他的腳本都是放在最底部，我又看了下汽車之家的選車也是，發現除了少量幾個控制樣式的js放在頂部，其他的也都放在了尾部。

前面提到對響應時間影響的是頁面中組件的數量。當緩存為空時，每個組件都會產生一個HTTP請求，有時即便緩存是完整的亦是如此。要知道瀏覽器會并行的執行HTTP請求，大家可能會問，為什么HTTP請求的數量會影響響應時間呢？瀏覽器不能一次將它們都下載下來嗎？對此的解釋要回到HTTP1.1規范 （我找了一個中文版的給大家），該規范建議瀏覽器從每一個主機名并行地下載兩個組件。關于瀏覽器的并行下載數：瀏覽器的并行下載進程數（firefox默認最多為6個，IE8據說最多為8個，opera 9和Safari最多 為4個）

很多WEB頁面需要從一個主機名下載所有的組件。查看這些HTTP請求會發現它們是呈階梯狀的.

瀏覽器的并行下載進程數是可以修改的，如使用Firefox中的插件FastestFox，但我們不應該依賴用戶來修改瀏覽器設置，這個可以簡單的使用DNS別名，來將組件分別放到多個主機名中(新浪微博把這點發揮到極點–10個圖片域名)。Yahoo的研究表明，使用兩個主機名比使用1、4或10個主機名能。

腳本阻塞下載

并行下載組件的優點是很明顯。但在下載腳本的時候并行下載實際上是被禁用——即使使用了不同的主機名，瀏覽器也不會啟動其他的下載。其中一個原因是，腳本可能使用了document.write來修改頁面內容，因此瀏覽器會等到，以確保頁面能溝恰當地布局。

正確地放置

我們使用的腳本加載時間很可能比我們預期的時間長很多，因為用戶的帶寬也回影響腳本的響應時間。

而在我們開發過程中，很多情況我們很難講腳本移到底部。比如剛才說得腳本使用了document.write向頁面中插入了內容，就不能將其移動到頁面中靠后的位置。

這里就出現了另外一種建議就是使用延遲腳本。defer屬性表明腳本不包含document.write，瀏覽器得到這一線索就可繼續進行呈現。但是如果一個腳本可以延遲，那么它就一定可以移到頁面底部。而且延遲腳本只適用于IE對火狐不好使。所以底部最優。